In an era when microprocessors and supporting devices are commonly rated at gigahertz clock speeds, the synchronization in timing between digital devices becomes ever more critical. At high speeds, even the propagation time required for a signal traveling from one digital device to another, or even from one part of a digital device to another part of the same device, becomes both a design and operational concern. Moreover, at such high speeds, concerns arise not only from the possibility of data taking too long to become available at a certain point in a device, but also from the possibility that data may be available too soon. Because digital devices operate at different speeds, it is clearly vital that devices disposed to operate in concert actually are synchronized in theft operations. If one digital device were, for example, to be operating one clock pulse ahead or behind a storage device from which the device receives data, the results generated by the device might be based on erroneous operands.
As a digital system grows in size, complexity, and number of devices it comprises, the effect of the heat generated by the devices affects the regularity of the phase 25 of the clock signal. Similarly, the switching of the many devices causes fluctuations in the supply voltage to the circuit, which in turn affects the supply voltage available to the devices and thereby affects the phase of the clock pulses. Literally, as a circuit becomes sufficiently complex, it becomes virtually impossible for a single clock source to pulse the entire circuit; switching of devices pulsed by that clock source creates such a large current drain on the clock source that it can become impossible for the clock source to maintain a clock signal having a consistent phase. Thus, as a circuit grows in complexity, it becomes necessary to add devices merely to proliferate clock signals with an adequate current to source to dependent devices.
Introduction of devices to proliferate these clock signals, however, introduces a competing concern: to avoid the very lack of timing synchronization these devices are introduced to correct. With continual changes in voltage and operating temperature, the outputs of these proliferation devices must be checked and synchronized to ensure that all the devices in the circuit operate with acceptable synchronization.
Various means have been used to proliferate synchronized clock signals in large circuits. One of these, a delay locked loop (“DLL”) subsystem, has proven to be a very workable and popular solution. Generally, a DLL includes its own clocking device synchronized to that of a system clock input. The DLL maintains its synchronization to the system clock through a network of digital delay devices which allow the DLL to apply a positive or negative delay to its clock signal to generate an output signal appropriately synchronized to the input signal. As the “loop” designation implies, the DLL monitors a feedback loop of its own output clock signal and compares it to an input clock signal—that of the system clock—to adjust the DLL output to keep it in phase with system clock.
DLL subsystems have proven to be very useful in random access memory 20 (“RAM”) devices in proliferating a system clock to synchronize the timing with which the data is read from the RAM device. Specifically, the DLL clocks output drivers of the RAM device to apply data to data bus terminals of the RAM device. The DLL in a RAM device monitors the system clock signal received by the RAM device and continually synchronizes its own clock signal output so that data is read from the RAM device in synchronism with the system clock signal. As is known in the art, the DLL incorporates a number of delay elements which can be switched as needed to effect the proper delay to synchronize the output of the RAM device with the appropriate edges of the system clock signal. As noted, the DLL monitors the system clock signal and is thus immune to variations in operating temperature and fluctuations in device supply voltage which could disrupt its synchronization with the system clock. As a result, data stored in the RAM device is read from the RAM device at the appropriate time.
However, as more and more subsystems are introduced to the RAM device, including subsystems like the DLL which are employed merely to support the function of other devices, the power consumption of the RAM device can become extensive. This power consumption can generate excessive heat, which generally is undesirable for many reasons, not the least of which is the effect that introduction of additional heat has on maintaining a regular clock signal, as previously described.
A greater concern in adding additional devices is magnified by the 10 increasing popularity of portable digital devices, evident by the proliferation of portable computers, digital wireless telephones, personal digital assistants, digital music players, and similar devices. As users come to depend on these devices more and more, users need to be able to operate these devices for longer periods of time on a single charge or set of batteries. Although power source technology has improved, arguably, still the most significant measure that can be taken to increase battery life is to reduce the power consumed by these devices.
One of the clearest ways for such a device to save power is to shut down subsystems that are not in use. To take one example, when a user puts a portable computer in a standby mode, many devices in the system, ranging from the display and the circuits which support it, to the input-output devices and the circuits which support them, are shut down. Similarly, portable computers and other devices commonly can be programmed to power themselves down to a standby mode when no user or system commands have been issued during the passage of a preselected period of nonuse, Obviously, some systems cannot be shut down without obliterating the usefulness of the information; most notably, RAM devices must continue to receive power, or their contents will be lost. Further, as is known in the art, the memory cells of dynamic random access memory (“DRAM”) devices must be regularly refreshed to preserve the integrity of their contents.
In a power-saving standby mode, these DRAM devices typically enter a self-refresh mode in which their contents are refreshed at the direction of an onboard self-refresh controller and clock. The onboard self-refresh control systems exploit the fact that the lack of external commands places DRAM devices in a reasonably stable state. Because the self-refresh state comprises a continual cycle of refresh commands, without sporadic system commands being received, current leakage that degrades the ability for DRAM memory cells to maintain their contents is reduced. As a result, the self-refresh control systems can employ a longer interval between row refreshes, thereby saving power.
Data is not read from a DRAM device when it is in a self-refresh mode. Consequently, there is no need for the DLL subsystem to constantly synchronize its delay interval to that of the system clock during the self-refresh mode. It is known in the art that the DLL subsystem can be locked upon the DRAM device entering a self-refresh state. More precisely, the delay interval used by the DLL subsystem is locked upon the DRAM device entering the self-refresh state.
FIG. 1 depicts a conventional DRAM device 100, directed by control logic 105, with a DLL subsystem 110. Specifically, a self-refresh command is triggered by the system driving the RAS* 120 (row address strobe—low enable) and the CAS* 130 (column address strobe—low enable) control lines low, and by also driving the CKE 140 (clock enable) control line low. This command causes the self-refresh control logic to periodically and repeatedly refresh every one of its rows, and also places all the control lines into a “don't care” state, with the exception of the CKB 140 control line. The self-refresh state ends when the CKE 140 control line is driven high. At that point, after a waiting interval described below, the system can then access the DRAM device for read and write operations and/or to control the refreshing of the DRAM device through auto-refresh commands. Existing DRAM devices recognize that, when the CKB 140 control line is driven low, the DLL 110 subsystem can be disabled to save the power that would be wasted in its devices switching to synchronize its own clock output with that of the system clock supplied to the DRAM device 100 at the CK 150 (clock—low) and CK 160 (clock) inputs.
It is also known that, to enable the DLL 110 to function effectively upon the DRAM device 100 exiting self-refresh state when the CKE 140 control line is driven high, that the delay interval employed by the DLL 110 should be “frozen” at the delay state employed at the time the CKE 140 control line was driven low. Freezing the delay interval makes it possible for the DLL 110 to clock the DRAM device 100 without an extended delay or startup interval having to be afforded the DRAM device 100 upon it exiting self refresh mode. Freezing the delay interval, basically, allows the DLL 110 to pick up where it left off when the self-refresh mode was entered, giving the DLL 110 a head start in achieving synchronization with the system clock. As a result, some power is saved by preventing DLL 110 switching when the DLL 110 is not needed during self-refresh mode.
Other than during self-refresh states, there are other times that a DRAM 10 device 100 will not need not be actively outputting data, and, therefore, it is not necessary for the DLL 110 to constantly be switching to fine tune its synchronization with the system clock. Thus, it is conceivable that power potentially wasted on needless switching of the DLL 110 might be further saved during these times. It is to this end that the present invention is directed.